문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 Windows API (문단 편집) == 그 외 == * {{{A}}}함수와 {{{W}}}함수가 나뉘어 있다. 예시로 {{{MessageBox()}}}매크로를 예로 들면 컴파일 옵션에 따라 최종적으로 {{{MessageBoxA()}}} 또는 {{{MessageBoxW()}}} 로 변환되게 되는데 전자의 경우 시스템 로케일을 사용하며 (ANSI의 A) 후자는 유니코드 (UTF-16LE, Wide의 W)를 사용하게 된다. * 이러한 특징으로 {{{TCHAR}}} 이라는 매크로 자료형이 사용된다. 명시적으로 A 또는 W를 프로그래머가 알고서 사용하는 경우는 아무 문제가 되지 않지만 이해 없이 섞어 쓰는 경우 런타임 오류를 내기 때문. * {{{Windows 98}}}과 같이 {{{Windows NT}}} 커널이 탑재되기 이전의 OS의 경우 이 Wide 버전을 지원하지 않았으며 별도의 호환성 레이어를 설치해야 이런 유니코드 기반 프로그램을 동작시킬 수 있었다. * {{{A}}} 버전의 함수를 호출해도 커널 내부적으로는 {{{W}}} 함수를 최종으로 실행하게 된다. (A()->MultiByteToWideChar()->W();) * Windows API라는것 자체는 Windows 1.0 때부터 이어져 온 것이다 보니 시대가 지나며 기능이 추가되거나 없어진것도 있고 아무 의미 없이 존재하는것이 있다. 대표적으로 엔트리포인트인 {{{WinMain()}}}의 {{{hPrevInstance}}}가 있다.[* 첫번째 창을 띄운뒤 두번째 창부터 클래스 등록을 생략하고 기존 클래스를 재사용하기 위한 용도였으나 32비트 윈도우부터 무조건 클래스를 등록하는 것으로 변경되며 그 역할이 사라졌으나, 기존 시스템과의 호환성을 위해 남겨져 있다.] * 마찬가지로 원형과 {{{Ex}}} 버전이 별도로 존재한다. 기능이 추가되었지만 하위호환성을 위해 원형을 남겨 둔 것으로 {{{CreateWindow()}}}가 있다. 본래 함수였으나 현 SDK는 매크로로 되어 있으며 실제로는 {{{CreateWindowEx()}}}를 실행시킨다. 위의 경우와 마찬가지로 Win16 시절의 잔재들이 이런 경우다. * {{{MAX_PATH}}}라는 260로 정의된 매크로가 있다. 이 값은 Windows API나 그 API를 사용하는 프로그램 전역에서 경로 관련해서 사용되는데 260이라는 수에서 보이듯이 파일의 전체 경로가 260자를 넘을 수 없다. 이는 Windows NT 커널과는 관계가 없는데, [[NTFS]]문서에서 보이듯이 MAX_PATH보다 긴 경로를 가지는 것이 가능하지만 이 제한은 하위호환성에 따른 잔재이다. 이를 우회하기 위해서는 UNC경로를 사용하거나 [[Windows 10]] [[Windows 10/버전/Redstone 1|1607]] 부터 추가된 Application Manifest를 사용해서 프로그램이 260자보다 긴 경로에 대한 대비가 되어 있음을 선언하거나 레지스트리를 통해 시스템 전역으로 사용할 수 있는데 이는 {{{CreateFileW()}}}와 같은 [[유니코드]] 기반 프로그램에서만 이 제한을 넘을 수 있고 {{{CreateFileA()}}}같은 ASCII 기반의 API로는 여전히 260자로 [[https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation|제한된다.]] 유니코드여도 이 매크로를 사용해서 {{{wchar_t path[MAX_PATH];}}} 같은 식으로 작성된 프로그램들은 여전히 260자로 제한된다. * 경로나 레지스트리 상관 없이 개별 파일명은 MAX_PATH의 제한을 받는다. Windows API중 파일 목록을 받아 오는 API가 사용하는 {{{WIN32_FIND_DATA}}} 의 멤버인 {{{cFileName}}}이 MAX_PATH로 고정되어 있기 때문. * 16비트, 32비트 환경의 x86 한정으로 콜링 컨벤션이 뒤섞여 있다. 64비트인 [[AMD64]]나 [[AArch64]]의 경우는 주로 사용되는 호출 규약이 하나뿐인 반면 32비트의 경우 여러 컨벤션이 사용된다. 16비트 시절 컴퓨터의 메모리가 한정적일 때 함수 호출에 필요한 메모리 사용을 줄이기 위해 피호출 함수가 스택 포인터를 정리하는 [[파스칼(프로그래밍 언어)|파스칼]] 방식을 사용하다 32비트 시대로 넘어와서 이 방식을 약간 변경해 {{{stdcall}}}이라는 변종을 만들어서 사용했다.[br]다만 피호출자가 스택을 정리하는 방식은 [[C 언어]]의 가변인자를 사용할 수 없기 때문에 가변 인자가 필요한 부분은 소스코드에 명시적으로 cdecl을 사용해 코드를 생성하도록 지정 해 줘야 했으며 이 때문에 특히 심볼 로딩을 사용해서 코드를 작성 하는 프로그램들의 경우 이 부분을 까먹고 작성하지 않는 경우 런타임에서 오류가 생기거나 스택 메모리가 손상되는 등의 여러 장애물들이 있었다. * 공식적으로 API 자체는 일단 개요 문단에서 언급 된 언어만을 지원하지만 [[Microsoft]]의 프로젝트중 하나로 [[Rust(프로그래밍 언어)|Rust]]를 위한 래퍼가 제작되고 있다. Win32라 불리는 전통적인 API셋 부터 모던 API인 WinRT 까지 사용이 가능하며 [[DirectX]]관련 API도 지원하고 있다. 또한 커널 드라이버를 위한 WDK또한 래핑이 되어 있다. [[https://github.com/microsoft/windows-rs]]저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기